Understanding migration

Unisphere supports a migration application to provide a method for migrating data from a source storage system to a target storage system.

Migration can be defined as a one-way movement of an application or applications from a source storage system to a target storage system with the intention of retiring the source.

PowerMax Data Mobility can be defined as the ongoing movement of data of an application between storage systems for various reasons: load balancing, performance optimization, HA, and migration. Data Mobility incorporates Non-Disruptive Migration (NDM), Minimally Disruptive Migration (MDM), and Open Minimally disruptive migration (O-MDM).

NDM provides a method for migrating data from a source storage system to a target storage system without application host downtime. NDM enables you to migrate storage group (application) data (the storage groups must have masking views) in a non-disruptive manner with no downtime.

MDM enables migrations on the same supported platforms as non-disruptive migration it but requires a short application outage. The outage is because that the non-disruptive nature of migration is heavily dependent on the behavior of multi-pathing software to detect or enable or disable paths and is not in the control of Dell (except for PowerPath).

NDM provides non-disruptive and minimally disruptive support from VMAX3, VMAX All Flash, and PowerMax arrays running 5977 and 5978 firmware to PowerMax 2500/8500.

O-MDM provides integration of Open Replicator into Data Mobility allowing automation of migrations. Provides migration from any VMAX array (5876, 5977, 5978), Unity, XtremIO, or any FC connected array to a PowerMax 2500 or PowerMax 8500 storage system.

Metro-based NDM is built upon SRDF/Metro active/active technology with the Metro instant activate (Metro-IA) feature. Benefits of using Metro-based NDM include the following:

  • Allows the complete migration from a VMAX3 or VMAX All Flash arrays to VMAX All Flash or PowerMax arrays without the need for downtime.
  • Leverages Metro technology to reduce the required commands users must issue by removing the need to cut over.
  • Manageable by familiar and simple user interfaces: Solutions Enabler and Unisphere for PowerMax.
  • Allows migrations to be canceled and failed back to the source array for any reason before commit.
  • Allows users to precopy all or a large portion of data before bringing the host live to the new array. The precopy reduces the impact to the application during the migration period.

More migration information is available in the Solutions Enabler Array Controls and Management CLI User Guide and the Non-Disruptive Migration Best Practices and Operational Guide. Source side service levels are automatically mapped to target side service levels.

Non-Disruptive Migration applies to open systems or FBA devices only.

Non-Disruptive Migration supports the ability to reduce data on all-flash storage systems while migrating.

A Non-Disruptive Migration session can be created on a storage group containing session target volumes (R2s) where the SRDF mode is synchronous. The target volumes of a Non-Disruptive Migration session may also have a SRDF/Synchronous session that is added after the Non-Disruptive Migration session is in the cutover sync state.

Suggested best practices

  • Try to migrate during slow processing times; QoS can be used to throttle copy rate.
  • Use more SRDF links, if possible, to minimize impact:
    • Two is the minimum number of SRDF links allowed; Non-Disruptive Migration can use up to eight SRDF links.
    • More links = more IOPS, lower response time.
  • Use dedicated links as they yield more predictable performance than shared links.

You can migrate masked storage groups where the devices can also be in other storage groups. Examples of overlapping storage devices include:

  • Storage groups with the exact same devices, for example, SG-A has devices X, Y, Z; SG-B has devices X, Y, Z.
  • Devices that overlap, for example, SG-A has devices X, Y, Z ; SG-B has devices X, Y.
  • Storage groups where there is overlap with one other migrated SG, for example, SG-A has devices X, Y, Z ; SG-B has devices W, X, Y; SG-C has devices U, V, W.

The following migration tasks can be performed from Unisphere:

  • Setting up a migration environment—Configures source and target storage system infrastructure for the migration process.
  • Viewing migration environments
  • Creating a Migration session—Duplicates the application storage environment from the source storage system to the target storage system.
  • Viewing Migration sessions
  • Viewing Migration session details
  • Cutting over a Migration session—Switches the application data access form the source storage system to the target storage system and duplicates the application data on the source storage system to the target storage system.
  • Optional: Stop synchronizing data after Migration cutover and Start synchronizing data after Migration cutover—stop or start the synchronization of writes to the target storage system back to the source array. When stopped, the application runs on the target storage system only.
  • Canceling a Migration session—cancels a migration that has not yet been committed.
  • Committing a Migration session—Removes application resources from the source storage system and releases the resources that are used for migration. The application permanently runs on the target array.
  • Recovering a Migration session—Recovers a migration process following an error.
  • Removing a migration environment—Removes the migration infrastructure.